In a database system, a trigger defines a set of actions that are executed when a delete, insert, or update operation occurs on a specified table or view. When such an operation is executed, the trigger is said to be “activated”. Triggers are usually defined and activated along with referential constraints and check constraints to enforce data integrity rules. For example, before inserting into an employee table, the new data such as employee's birth date and social security number should be validated and after the insert is done, corresponding rows should be added to the employee tax and salary tables.
Because triggers move the business rule application logic into the database system, managing triggers becomes an important task for the database administrators. Similar to applications, logic can be changed and new actions may be needed in triggers. To do so, the existing trigger must be deleted or “dropped”, and then the trigger must be recreated with the changed or new actions. Dropping a trigger requires an invalidation process, including invalidating statements that cause the trigger to be activated that may still be stored in memory, making the changing of triggers inefficient. Further, the dropping of a trigger with the intent to change the definition and “redefine it” will affect the trigger activation time. Thus, if multiple triggers are defined on a table for the same triggering event, they are activated in the order in which they were defined. If a trigger in a middle of the order is dropped and recreated, then this recreated trigger will be placed at the end of the order instead of its original place.